Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/telnet/telnet-minutes-91mar.txt

Text File | 1993-02-17 | 9KB | 212 lines

CURRENT_MEETING_REPORT_


Reported by David A. Borman/Cray Research, Inc.

TELNET Minutes

Agenda


   o Telnet Environment Option
   o Telnet Authentication Option
   o Telnet Encryption Option


The Telnet Working Group met the morning of Tuesday, March 12, 1991, and
the afternoon of Wednesday, March 13, at the St.  Louis IETF meeting.

Telnet Environment Option

The first item of discussion was the ENVIRON option.  Vint Cerf was
present to express some of the views of the IAB on this option, and
their reluctance to endorse it.

The crux of the issue is the fact that the ENVIRON option allows for
arbitrary environment variable information to be passed between systems
and that the draft RFC has no well-defined variables in it, the lack of
the latter causing even more concern about the former.  Vint suggested
that submitting the ENVIRON option with some well defined variables, and
without the unknown variables being allowed, unless there was some good
justification, could expedite the IAB accepting the ENVIRON option.

A list was put together of what well known variables should be in the
initial draft:  The list was USER (LOGNAME), JOB, ACCT, PRINTER,
SYSTEMTYPE and XDISPLAY. Dave Borman will write up a description of the
format of the values for these and send them to the mailing list for
discussion.

Because there is a strong feeling that giving the user the ability to
pass arbitrary environment variable information is very useful,
discussion was held on how to continue.  One item that has to be done is
to identify how to differentiate between well known variables and
user-defined variables.  One option was to encode the information in the
variable name, for example, ala the X-foo naming used in mail.  The
other option was to add a new code, USERVAR, that would have the same
semantics as VAR, but be explicitly for non-standard variable names.  A

                                   1






vote was taken, with three options:


  1. Encode information in name.
  2. Add USERVAR.
  3. Leave it out for now, and don't worry about it.


With seven votes recorded, three voted for adding USERVAR, one voted for
encoding in the name, and three voted for leaving it out for now.
Hence, any future discussion for dealing with user-defined variables
will use the USERVAR code.

Dave Borman will look into Vint' suggestion that it might be good for
someone to go to an IAB meeting and present the reasons for the
user-defined variables.

Telnet Authentication Option

The Authentication option was next on the Agenda.  The revised draft,
with definitions for Kerberos Version 4, was discussed.  It became
apparent that the NAME subcommand in the Kerberos definitions was
something that could be needed by many authentication schemes, so the
NAME suboption was moved up to its own suboption:



     IAC SB AUTHENTICATION NAME remote user IAC SE



Two new options for Kerberos were added, CHALLENGE and RESPONSE, to
provide mutual authentication.  After the server authenticates the
client, the client sends the server a CHALLENGE, an eight octet value
encrypted in the session key.  The server decrypts it, adds one to it,
re-encrypts it, and sends it back in a RESPONSE command.  If the client
can successfully decrypt it, and get the original challenge value plus
1, then the server has been authenticated to the client.  As an
additional step, both sides take the original encrypted challenge, and
encrypt it again in the session key, and save that new value for a
unique encryption key that can be used by the ENCRYPT option.  Hence,
the NEWKEY command isn't needed anymore, and was therefore removed.  The
ACCEPT command was modified to remove the optional ``authenticated
principal'', as it provided no new, useful information.  There was a bit
of discussion about the difference between authentication and
authorization.  A user may be able to authenticate on the remote
machine, but still not be authorized to log in as the user specified in
the NAME suboption.  Also, this knowledge might not be known to the
telnet server.  Hence, the Kerberos REJECT command may or may not

                                   2






contain an explanation, and the client might well get an ACCEPT command,
only to then later see a failure message from some other part of the
remote system that failes the authorization.

A decision was made that, with these changes, the authentication option
is fairly stable.  The changes will be incorporated into the document
and distributed for review, and if there are no major objections it will
be sent off to be published as an RFC. The Kerberos definitions will be
removed and published as a separate document.

Telnet Encryption Option

One item of a rather lengthy discussion entailed the security aspects of
the Encryption option.  The net result was that it was decided that for
now the document would state that the encryption option provides
protection against a passive attacker (i.e, someone who is snooping in
on the packets as they fly by), but not against an active attacker
(i.e., someone who is snooping, and can also intercept/modify the
packets as they fly by).  The crux of the discussion was for when the
encryption option is normally off, and is only being enabled in one
direction when sensitive information is passing over the network, like
passwords.  Later versions of the option may contain information about
how to provide adequate protection against an active attacker.

Key exchange was also discussed.  In all cases, key exchange is
currently outside of the scope of the Encryption option.  It is assumed
that there are one or more keys available that are known to each side of
the connection.  It was decided that the START and REQUEST-START would
have an additional argument added, a keyid.  A keyid is an arbitrary
length number.  It is encoded with the MSB first, and the LSB last.  All
the bytes between the START/REQUEST-START and the IAC SE are the keyid.
A one-byte keyid with a value of zero was reserved to mean ``the default
key''.  This will usually refer to a key derived as a side effect of
authentication.  For all other keyids, an algorithm is needed to do the
exchange of information to decide which key name to use.  David Borman
agreed to write something up on this.



     [ Begin additional info, not part of the minutes of this
     meeting ]
     What will be in the next draft is the addition of two new
     commands:  ENC _KEYID and DEC_KEYID. The side that is going to
     encrypt sends ENC_KEYID with a keyid that it understands.  The
     decrypting side responds with a DEC_KEYID command with the same
     value if it accepts it, a different value if it doesn't accept
     it but has a different keyid to try, or an empty value if there
     are no more values.  If the encryptor receives a different
     value than what it sent, it processes it in the same way,
     sending over one of the three possible responses.  This

                                   3






     continues until both sides have sent and received (or received
     and sent) the same value.
     [ End of additional info ]



The inital description on Kerberos DES encryption that was in the latest
draft document was modified quite a bit.  It was decided that we needed
a definition for both Cipher Feed Back (which is what was already
documented, more or less...)  and for Output Feed Back.  The Initial
Vector is sent by the encryptor, and is sent as a clear text string
across the network.  The view was that this was probably okay, but there
was some concern that it might need to be encrypted.  However, for now
it will just be clear text.  The encrypter sends across the IV, and the
decryptor sends back either an IV_OK or IV_BAD message.  If IV_OK is
received, then negotiation of the keyid, happens, and then encryption
can be enabled/disabled as needed.

The Telnet Working Group will meet at the July IETF Meeting in Atlanta.

Attendees

Richard Basch            [e-mail]
David Borman             [e-mail]
Vinton Cerf              [e-mail]
Tom Grant                [e-mail]
Neil Haller              [e-mail]
Russ Hobby               [e-mail]
John Linn                ULTRA::LINN
David Lippke             [e-mail]
George Sanderson         [e-mail]
Jeffrey Schiller         [e-mail]
Sam Sjogren              [e-mail]
Dean Throop              [e-mail]
William Townsend         [e-mail]
Kathleen Wilde           [e-mail]



                                   4